很多程序设计师并未下功夫研究如何清除Bug。很多人都是直接去看原始码，随便修改某个地方，再执行一次看看Bug是否还在，如果还在，就回来改另一个地方，猜猜看是不是这儿错了，如此猜了一回又一回……直到Bug消失。
我之所以知道程序设计师用猜的方式找错，是因为当他们实在找不出Bug在哪里时，就过来问我，“接下来该怎么办？”这种心态好像是在游戏结束前“不玩了”，并不是真正在寻找Bug出现的原因。
以我的经验，最有效的除错方式是用debugger（除错工具）设定一个暂停点，当程序执行到暂停点时，一一检视变量的值是否正确，如果不对，针对这个变量往前找它的变化，如果变量全对，就往下再设一个暂停点，继续执行到那里再来看变量对不对。即使程序极复杂，要在庞大的数据结构中转来转去，用这种方法总可以找到错虫，比起用猜的方法要有效多了，如果靠猜测来找错，即使猜中也不过是运气好，未必能找出Bug出现的真正原因。
我同时要提醒那些用看程序的方式来找错的人，应该去读一下安德鲁·科恩尼（AndrewKoenig）的《C语言陷阱》（CTrapsandPitfalls）一书，里面有很多C程序的范例，看起来都完美无瑕，但都有微妙的错误。要不然，有些杂志定期会介绍一些附范例的C程序除错的技巧，也不妨看看。用看程序的方式找错，是既懒惰又无效率的方法，用debugger来找错虫是最快又最方便的，观察各变量在程序执行过程中的变化，是非常有效的方法，绝对不要用猜或用看的方法来找错。
在这个案例中，Word小组为了对话窗的速度问题抱怨了好几个月，使得做对话窗函数库的小组花了好多时间，辛辛苦苦地把程序最佳化，希望这是最后一次修改，可以满足Word小组的需求。其实，只要有人去看一下Word是怎么处理对话窗函数呼叫的，那问题早就迎刃而解了。
当然，不应该要求函数库的制作小组来测试应用程序，因为调用这个函数库的应用程序总有数十上百种。然而，函数库小组自己也该积极点，应该做一个专门测试本函数库的假应用软件，对函数库单独测试，就能为函数库本身的质量建立信心指导。在本例中，Word小组已经大声地抱怨了很久，而且函数库小组也找不出Word在调用时有没有弄错，我相信在我之前一定有人发现了只有第一次特别慢的现象，却没有认真研究这一点，而把问题的焦点放在把函数库最佳化上面，使得函数库小组无形中背了个黑锅。
身为主管的您，得随时睁大雪亮的眼睛，看看是不是有个悬而未决的问题，一定要有个人（或是由主管自己）来负责研究到底哪里出错，也许这种研究既花时间又无聊，但总比灾难发生之后再来花好几个星期收拾残局要好得多。
 |
